1. Field of the Invention
The present invention generally relates to the field of processing statements and expressions, including rights expressions, and more particularly to a method, system, and device for determining authorization of rights expressions with respect to a trust root.
2. Discussion of the Background
The digital age has greatly increased concerns and capabilities about ownership, access, and control of copyrighted information, restricted services and valuable resources, as well as electronic communications through e-mail, by way of the internet and other means, and electronic transactions, such as electronic or automated purchase and sale of goods and services. Rapid evolution and wide deployment has occurred for computers, and other electronic devices, such as cellular phones, pagers, PDAs, pocket PCs, music players, and e-book readers, and these devices are interconnected through communication links, including the Internet, intranets, and other networks. These interconnected devices are especially conducive to publication of content, offering of services, and availability of resources electronically.
One of the difficulties facing the widespread distribution of digital works (e.g., documents or other content in forms readable by computers), via electronic means, and the Internet in particular, is the enforceability of the intellectual property rights of content owners during the distribution and use of digital works. One of the difficulties facing digital commerce, including the distribution and use of goods and services, is the ability to securely and effectively process electronic transactions and, in particular, to do so in accordance with the requirements of the parties involved in the transaction.
Efforts to resolve these difficulties have been termed “Intellectual Property Rights Management” (“IPRM”), “Digital Property Rights Management” (“DPRM”), “Intellectual Property Management” (“IPM”), “Rights Management” (“RM”), and “Electronic Copyright Management” (“ECM”), collectively referred to as “Digital Rights Management (DRM)” herein. There are a number of issues to be considered in effecting a DRM System, such as authentication, authorization, accounting, payment and financial clearing, rights specification, rights verification, rights enforcement, and document protection. U.S. Pat. Nos. 5,530,235, 5,634,012, 5,715,403, 5,638,443, and 5,629,980, the disclosures of which are incorporated herein by reference, address such issues.
In a simple DRM system for managing the distribution and use of digital works, one agent issues a rights expression to another agent, which processes the rights expression, and recognizing the first agent as authorized, acts upon that rights expression. In this simple model, the recognition of the first agent by the second is innate or hard-coded. As a DRM system evolves, more and more agents wish to issue rights expressions and use the DRM system for their assets. With the addition of these new rights expression issuing agents, a solution other than innate or hard-coded recognition of agents issuing rights expressions becomes desirable.
One such approach is the use of certificates to certify agents issuing rights expressions. Such certificates then are used by other agents to recognize the certified agents. In this approach, one certified agent issues a rights expression to another agent, which then processes the rights expression, verifies the certificates associated with the first (certified) agent, treats the first (certified) agent as authorized, if it recognizes the trust root of the certificate chain, and then acts upon that rights expression. Certificate languages, such as X.509 and SPKI, allow only relatively simple conditions, primarily validity time intervals, in each certificate. Accordingly, the most common certificate chain verification algorithms for these languages (e.g., Internet Engineering Task Force (IETF) RFC 2459, and RFC 2693, respectively) are relatively straight-forward to execute.
As a DRM system continues to evolve and more and more agents become certified to issue rights expressions, eventually concerns may arise about one certified agent issuing rights expressions, either intentionally or accidentally, over another certified agent's assets, thus leading to the compromise of that asset. One approach that can be taken to address this concern is described in detail in the OMA DRM 2.0 Specifications issued by the Open Mobile Alliance, an industry consortium whose mission is to facilitate global user adoption of mobile data services. The OMA specifications involve requiring each certified agent to know the content encryption key for each asset for which it issues rights expressions.
Another approach is to scope (e.g., limit) each agent's certification to issue rights expressions to apply only to the assets it owns or controls. Determining the correct scope for each certificate takes some work, but is doable. The expression of such scoping can be accomplished using, for example, techniques described in U.S. patent application Ser. No. 10/162,701 to Xin, et al., entitled “METHOD AND APPARATUS MANAGING THE TRANSFER OF RIGHTS” and U.S. patent application Ser. No. 10/298,872 to Atkinson, et al., entitled “DIGITAL LICENSES THAT INCLUDE UNIVERSALLY QUANTIFIED VARIABLES,” and a rights expression language, such as ODRL, XrML or as adopted by the Moving Picture Experts Group (MPEG) as an international standard (ISO/IEC 21000-5) known as the ISO MPEG REL. Such an approach also can involve a more sophisticated chain verification algorithm to verify the scope in each certificate, for example, as described in U.S. patent application Ser. No. 10/856,865 to Lao, et al., entitled “NETWORKED SERVICES LICENSING SYSTEM AND METHOD,” although execution of such algorithm is still relatively straightforward, as long as the conditions in each certificate remain relatively simple.
At this stage of DRM evolution, the technology includes approaches (other than innate or hard-coded) for verifying the authorized issuance of a rights expression, such as 1) unscoped certificates with the issuance of rights expressions requiring knowing the content encryption key, and 2) scoped certificates.
As DRM business models continue to evolve, users should become more interested in the independent trade of rights (independent from the trade of the underlying assets). A person should be able to trade any rights in any territory or field for any digital work or service. For example, a person should be able to trade rights to a suite of web services or to view in the United States all current and future publications of a particular publisher on a particular topic. In such cases, requiring knowledge of the appropriate content encryption key for each trade becomes limiting, because there is not a clear mapping from a rights expression to a single asset being traded. In this respect, the scoped certificates approach is advantageous because it does not limit the issuing of potentially overbroad rights expressions and instead limits the certificates' effect, as part of the chain verification algorithm.
For example, a scoped certificate might say that agent Publisher 1 may issue rights expressions pertaining to paperback Book 1. Publisher 1 might actually issue a rights expression to agent Consumer 1, allowing Consumer 1 to view any paperback book. When these two rights expressions are put together and the chain verification algorithm is executed, Consumer 1 only will be able to view paperback Book 1. However, if another scoped certificate is later added that says that Publisher 1 may also issue rights expressions pertaining to paperback Book 2, then by putting all the rights expressions together, Consumer 1 will be able to view both paperback Book 1 and paperback Book 2 (since Publisher 1 said Consumer 1 could view any paperback book and since Publisher 1's issuing ability is scoped to paperback Book 1 and paperback Book 2).
As the business of trade in rights continues to expand, publishers may wish to engage retailers and other value-add providers in the rights expression chain between the publisher and the consumers. Moreover, publishers may wish to scope the rights-issuing capabilities of various retailers or other intermediaries in various ways, such as to certain territories or by requiring the payment of particular fees or by imposing other conditions on authorization to issue rights expressions. The types of conditions in the rights expressions that form the certificate chain can become very creative and complex, and the execution of the chain verification algorithm for such a chain becomes less straight-forward. Accordingly, there is a need to make the execution of this process more straight-forward, without sacrificing business model flexibility, technical features or security.
One of the potential difficulties in verifying a certificate chain, including creative conditions, is the information needed to execute the verification typically is not available. For example, consider a scenario including three agents, an author, a reader, and a friend. There is one rights expression that allows the author to issue rights expressions pertaining to his book. There is another rights expression from the author to the reader, allowing the reader to read the book, and issue up to two rights expressions, one each to two of his friends. There is a third rights expression from the reader to his friend, allowing his friend to view the book. When the friend wants to view the book, he will verify the certificate chain, including the rights expressions, and at some point will have to determine if the reader has satisfied the condition of issuing only up to two rights expressions. A problem thus arises if for any reason the information is not available (e.g., the reader might not have kept all required information or might have discontinued providing information in an accessible format). If, however, the reader does keep track of this information, he might not be available for contact by the friend. The reader also might have stored this information at some place that is available for contact, but that place may have a privacy policy or technology limitation, which prohibits or prevents it from sharing that information with the friend.
One possibility is that the information about the number of rights expressions the reader has so far issued is stored in the rights expression that the friend receives. Assuming the friend has access to this information somehow, the friend still has to validate the “at most two rights expressions” condition using the information. However, this means that the friend has to understand what the condition means. In some situations, the friend may be using outdated software or hardware, and may not be able to support all the latest conditions being used by the author and the reader. This means that the author and reader cannot upgrade the conditions they use, unless the friend also updates the conditions it can understand. One solution to this, is to store the information about satisfaction of conditions in a way that the friend can process that information, without having detailed knowledge of the condition (e.g., by comparing the names of satisfied conditions with the names of conditions that need to be satisfied).
However, there is a further issue where the friend has access to the information about and names of the conditions under which the reader can issue rights expressions, because in some situations it is not desirable to share the information, such as where the information is considered confidential. For example, if there is a fee associated with the reader giving his friend a rights expression as a gift, the reader may not wish his friend to know the price of the gift. To solve this concern, the condition information might be encrypted so that the friend cannot discern it, but the friend's software or hardware can process it. This extra encryption, however, also complicates the system design to some degree. In situations where knowledge of the details of the conditions is more sensitive than the actual assets themselves, the cost of the encryption needed on the conditions could be disproportionate to the asset's value.